home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Oct 89 / Z0071-Eiffel-Oct89 < prev    next >
Encoding:
Text File  |  1989-10-13  |  3.6 KB  |  89 lines  |  [TEXT/GEOL]
  1. Item    2889822                         13-Oct-89        09:55
  2.  
  3. From:   D1282                           Power Up,PRT
  4.  
  5. To:     MACAPP.TECH$                    MACAPP Tech
  6.  
  7. Sub:    Eiffel
  8.  
  9. Attn:  MacApp.Tech$
  10. SentBy: James Plamondon
  11. Date   10/13/89
  12. Subject    Eiffel
  13. From   James Plamondon
  14. To  MacApp.Tech$
  15.  
  16. Subject:   Eiffel
  17. Dear M. Muys-Vasovic,
  18.  
  19. Thank you for your response to my link regarding Eiffel and Meyer’s book.
  20. Your criticism of the book’s unabashed promotion of Eiffel, its “requirements”
  21. for an OOP language that — surprise! — only Eiffel meets, and its offhand
  22. dismissal of C++, are all quite valid, in my opinion.
  23.  
  24. I am intrigued by some of your other comments, however, and would like to have
  25. you elaborate on them further, if you would.
  26.  
  27. You mention that multiple inheritance (MI) is badly implemented in Eiffel, and
  28. that specifically, “renaming is terrible.”  What specifically is wrong with
  29. renaming, generally and/or as implemented in Eiffel, what alternatives are
  30. there to renaming, and what are advantages and disadvantages of these
  31. approaches compared to renaming and to each other?  (OK, that’s a big
  32. question, but I’ll gladly accept an answer to any part of it that I can get.)
  33. Renaming looked pretty straightforward to me; evidently I’m missing something
  34. important here.
  35.  
  36. You also point out that Eiffel has no case statement.  I agree that this is
  37. indeed a deficiency.  Although many case statements are used to simulate
  38. polymorphism procedurally, certainly not all are used this way; why, I’m known
  39. to use a case statement now and again myself (although I won’t admit to using
  40. a GOTO).
  41.  
  42. Genericity, you say in your link, “is nice,” but that it can be seen as a
  43. special case of textural substitution.  If it were implemented using textural
  44. substitution, redundant code would be generated for each instantiation of a
  45. generic class.  Unless Meyer is flat-out lying, however, this is not the case
  46. in Eiffel.  If I may quote from the book (page 344, section 15.4.3: Space):
  47. “Neither genericity nor multiple inheritance result in code duplication.
  48. (Most implementations of Ada duplicate the code of a generic package for every
  49. instantiation; published descriptions of how to implement multiple inheritance
  50. in Smalltalk require that code for all routines not in the primary lineage be
  51. duplicated).”  (This mention of genericity is not indexed, and is easily
  52. overlooked.)
  53.  
  54. If this statement is accepted as being true (which seems only fair until
  55. proven otherwise), then genericity as implemented in Eiffel is more than just
  56. a special case of textural substitution.    I see genericity as being a very
  57. important part of the language — a part that is missing from almost every
  58. other language.  Am I making a big deal out of nothing?
  59.  
  60. Lastly, you state that you have mixed feelings about the Eiffel exception
  61. mechanism.  I will admit that I know nothing about exception mechanisms other
  62. than that which I have read in Meyer’s book (which we agree is biased in favor
  63. of Eiffel) and that which I have learned about failure handling in MacApp.
  64. What, then, are your thoughts on Eiffel’s exception handling?
  65.  
  66. I’m sending a copy of this link to MacApp.Tech$, to gather up as many
  67. responses as I can to these questions.  I think just about every MacApp
  68. programmer is beginning to look beyond Object Pascal, and since both C++ and
  69. Eiffel are essentially C preprocessors, and both will soon be available for
  70. MPW, this discussion is very pertinent and timely.
  71.  
  72.  
  73. Looking forward to your response, I remain,
  74.  
  75.  
  76. Yours,
  77.  
  78.  
  79. James Plamondon
  80. Software Engineer
  81. PowerUp! Software
  82. 2929 Campus Drive, Suite 300
  83. San Mateo, CA  94403
  84. (415) 345-5900 x351
  85. AppleLink: D1282
  86. CompuServe: 71230,734
  87.  
  88.  
  89.